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The universal development tool 

It's a complete solution 

Microprocessors are being hailed as the 
greatest invention since the transistor and as 
devices that will revolutionize our life styles. But 
before any of the advantages of microprocessors 
are realized, products must be designed, hard- 
ware tested, software written and the hardware 
and software integrated. 

That's the problem. Until recently with the 
introduction of disk-based development instru- 
ments with in-circuit emulation, there has been 
no single solution for developing microprocessor 
hardware and software and integrating the two. 
The disk-based development instruments offered 
so far have had one major flaw. They work with 
only one microprocessor. If you can afford to 
purchase new capital equipment and train your 
personnel on a separate instrument for each new 
microprocessor, they provide a solution. 

Millennium provides the complete solution to 
the development problem. With the introduction 
of the Universal One, Millennium offers the most 
cost effective instrument available today. The 
Universal One not only satisfies the micropro- 
cessor development needs of today, it provides 
for them TOMORROW. 
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For the most popular microprocessors now 
— and others in the future 

Millennium's Universal One is a disk-based 
microprocessor development instrument that meets 
the needs of the hardware engineer, the pro- 
grammer and the project leader. And, it provides 
easy-to-use techniques for implementing the most 
popular microprocessors; the 8080, 2650, and 
6800. Universal One can be used with other micro- 
processors in the future by simply adding a 
printed circuit card for each new microprocessor. 

The ability to interface with different micropro- 
cessors today and additional microprocessors in 
the future is the key benefit of the Universal One. 
It gives the system designer the freedom to 
choose the microprocessor best suited for an ap- 
plication without having to consider large capital 
expenditures for development instruments. Sys- 
tem designers are already finding themselves 
"locked-in" to a particular microprocessor simply 
because of heavy investments already made in 
personnel training, software, and 
development aids. This coi : ' 
easily lead to design 
compromises 
which would 
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The Master /Slave architecture interfaces 
multiple processors through a universal system bus. 



have an adverse effect on technical jjerformance 
or the ability to produce the most cost effective 
product. The problem becomes even more 
pronounced as the semiconductor industry 
steadily introduces new microprocessors into the 
market. 

Universal One will never be obsolete. The mul- 
tiple CPU architecture allows all user application 
functions to be controlled by the Slave CPU in 
one section of the instru- 
ment and all of the system 




appli- 
cation 
independ' 
or system 

related functions to be controlled by the Master 
CPU in the second section. Millennium will be 
providing additional Slave CPU boards as new 
microprocessors become available. 

You can interact with Universal One through 
the front panel controls or via a standard 
terminal. English-like commands control all 
instrument functions. 

Hardware and software debugging aids plus 
two stages of emulation help you move gradually 
from prototype design to full microprocessor 
system implementation. 

Universal One has a complete integrated 
PROM capability. Front panel sockets accommo- 
date the most commonly used PROMs; the 1702 A 
MOS erasable, the 82S115 family of bipolar 
PROMs, and the 2708. Others will be added in 
the future. The front panel sockets psermit PROM 
burning plus the ability to interchange data and 
programs between PROMs, disks, memory and 
other available peripherals. Tapes can also be 
made for automatic ROM masking. 



The Master/Slave Architecture 

The universal bus is the central element that 
ties the components together and permits the ex- 
change of data and control signals. The bus was 
designed to easily accommodate the addition of 
many major components without change. 

The dual (Master/ Slave) CPU architecture is 
the key element of the design. It enables the 
hardware to support new microprocessors with 
the addition of a Slave CPU 
' printed circuit as- 

sembly. The 
Master/Slave 
design also 
guarantees 
that Universal 
One will stay 
abreast of new 
technology. 
Most existing 
or future 16-bit 
and 8-bit pro- 
cessors can be 
easily added. 
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Separate Master/Slave functions. The Master serves the designer 
with a standard set o/ system services. Slaves perform hardware- 
dependent functions. 
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The universal development tool 



With big system software capabilities 

Universal Disk Operating System (UDOS) was 
developed specifically for and tailored to the 
multiple CPU architecture. The operating system 
is executed by the Master CPU in its own totally 
protected Master memory to prevent disruptions 
by application programs. The Master CPU controls 
multiple Slave CPUs that may have up to 65k 
bytes of slave memory. The operating system is 
universal and interfaces to any Slave supported 
by the system. 

UDOS is disk file oriented, and is designed to 
fully use the capabilities of the flexible disk storage 
device. Many file management functions are 
performed automatically by UDOS. You need not 
be concerned with the structure or internal work- 
ings of the file management system. Merely direct 
that certain data be stored on or taken from a file. 

UDOS was designed lor use by engineers as 
well as programmers. The system provides the 
capability to develop and check out application 
software efficiently. You do not have to be con- 
cerned about mistakes. UDOS makes it difficult 
to make big errors and easy to recover from 
little ones. 

The operating system allows development of 
microcomputer programs with a high level lan- 
guage (/x BASIC), a symbolic assembler, or with 
a combination of both. 

You can prepare a program with a powerful 
Text Editor, correct and modify it quickly and 
easily, then assemble it, load the resulting object 
code into Common memory (or into your applica- 
tion memory), and run it under debug control. 



During execution, the program steps can be 
traced, breakpoints can be set, and memory can 
be inspected and altered as required. Subse- 
quently, the program can be corrected or modi- 
fied at the source level, using the Text Editor, 
then re-assembled, loaded, and run again for 
the next round of debugging. 

You need not create a file or otherwise establish 
the file before writing data on it. When you issue 
a UDOS command with a file name as an output 
devicfe, and the file does not already exist, it will 
be created automatically and the given file name 
will be placed in the diskette directory. 

You need not allocate space for a file before 
using it. Diskette space is dynamically allocated 
by UDOS as it is needed. When the file is 
CLOSED, the space which was allocated for the 
file is recorded in the directory. When the file is 
DELETED, the space allocated for the file is 
opened for other files. 

Files can be concatenated (joined) into one file 
with a single UDOS command. This feature 
allows development of source programs in small, 
manageable pieces. Subsequently, all of the 
pieces can be combined and placed on a single 
file which can be assembled. If an error shows 
up in the assembly, only that "piece" of the source 
program which contains the error need be 
edited. All of the pieces can then be combined 
again and the assembly repeated. 

All of the peripheral devices attached to Uni- 
versal One are interrupt driven. This allows 
maximum use of Universal One's resources and 
greater throughput. 




All input/output operations are performed 
through logical channels. You can assign any 
physical device attached to Universal One to any 
one of eight logical channels. You need not con- 
cern yourself with the characteristics of the phys- 
ical device assigned to the channel. This feature 
allows preparation of programs whose input and 
output sources can be determined at run time. 
Channels can be assigned for a program exter- 
nally through the console, or internally by the 
program itself. The logical channel capability 
also allows you to attach your own device to 
Universal One and easily add a new I/O driver 
to UDOS. 

A sequence of UDOS commands can be exe- 
cuted one at a time for a "COMMAND" or proce- 
dure file. This feature provides the capability to 
invoke any number of UDOS commands simply 
by issuing the name of the command file. The 
individual UDOS commands in the file can be 
"filled" with parameters which are given at the 
time the file is invoked. This feature allows you to 
set up frequently used command sequences as a 
procedure which can be invoked simply. Com- 
mand files can be chained, i.e., the last UDOS 
command in a command file can be the name of 
another command file. This allows a series of 
jobs to be initiated for unattended processing. 
Text Editing 

For program editing and debugging tasks, Uni- 
versal One provides a file oriented line pointer 
editor. For advanced editing, macro and iteration 
capabilities permit combining multiple commands 
into one complex command that can be executed 
repeatedly. You can even use UDOS commands 
to initiate system functions during a text 
editing session. 
Debugging 

The instrument contains hardware assists to 
permit a complete and comprehensive debug 
package. The combination of debug hardware 
and software provides powerful capabilities. 
There are two memory address breakpoint regis- 
ters. These may be set to give a break on memory 
fetch only, memory write only or on memory read/ 
write access. Another capability is dynamic trace. 
This means that on an instruction by instruction 
basis, you can trace the activity of the program 
being executed, display the location of the instruc- 
tion, the mnemonic of that instruction, the register 
contents, and the state of the machine. 



There are two dynamic trace options available. 
You may trace every instruction or only the jump 
instructions. The jump instruction trace reduces 
printout time and executes through the program 
faster. If, however, you have isolated a problem 
area, you may then go back to a full trace mode 
and examine every instruction. There are com- 
mands that permit you to display and alter mem- 
ory. You may inspect and change the contents of 
the registers. You may interact with your program 
and change variables — change register contents 
and change the data elements being used in 
the debug process. The table lists the Debug 
module commands. 



DEBUG COMMANDS 


NORMAL SLAVE MEMORY 
(NON EMULATION) EMULATION MODE 


PROTOTYPE MEMORY 
EMULATION MODE 


DEBUG 


Yes 


Yes 


Yes 


TRACE 


All capability 


AU capability 


No Mnemonics or hex 
instruction printed 


SET (Piocessoi Registers) 


Yes 


Yes 


Yes 


RESCT (Slave Processor) 


Yes 


Yes 


Yes 


BICPT (Set Breakpoints) 


Yes 


Yes 


Yes 


CLBP (Clear Breakpoints) 


Yes 


Yes 


Yes 


PATCH 


Yes 


Yes 


No 


DUMP 


Yes 


Yes 


No 


EXAM 


Yes 


Yes 


No 



With multiple-mode emulation 

A primary value of Universal One to the hard- 
ware designer occurs when the software is inte- 
grated with the hardware. During integration, a 
cable is inserted into the microprocessor socket of 
the prototype (or breadboard) system. Universal 
One then provides multiple modes of real-time, 
in-circuit emulation. 

In one mode. Universal One emulates the pro- 
totype's microprocessor and its memory while 
input/output functions are controlled by your 
hardware. All of the debug commands (see table) 
are available to aid you in this mode. Once the 
prototype has been (debugged in this mode, the 
prototype uses its own memory and input/output 
capabilities. When the prototype is fully tested in 
this mode, the cable is removed and the micro- 
processor reinstalled. 

When operating with the prototypse memory, 
most of the debug features are still available. You 
can use the address breakpoint and perform a full 
trace. If this mode requires the use of PROM 
memory, the assembled program can be directly 
programmed into the PROM chips by Universal 
One. If the object program resides on papier tape, 
it can be loaded into Universal One and trans- 
ferred to the PROMs. 
With real-time trace 

Universal One's real-time trace capability 
provides a continuous record of 64 real-time 
processor transactions relative to a designated 
event. The events can be any combination of 
address, control, data or auxiliary data conditions. 
Memory Mapping 

You can map prototype or systems Slave mem- 
ory into the Slave microprocessor's address space 
in 256 byte blocks. This allows selective execution 
of programs in any combination of Universal One 
or prototype memory. 
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The universal development tool 

Universal Emulator 

If you have a means for assembling and 
debugging programs but need hardware emula- 
tion and PROM programming capabilities, the 
Universal Emulator is the solution. The Universal 
Emulator Instrument contains all the hardware 
emulation and PROM programming features of 
Universal One. 



With the Universal Emulator you can easily 
debug prototype hardware and integrate the 
software without having to build special test 
fixtures. Interaction with the prototype product 
is through the Universal Emulator's expanded 
front panel. 

If you decide you need the additional software 
capabilities of Universal One, you can upgrade in 
the field at any time by adding memory and the 
floppy disk subsystem. 




Universal Emulator 
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For fast, efficient programming 

/A BASIC is a proprietary software language 
developed by Millennium especially for micro- 
processor prototype development. It contains 
many of the same statements found in BASIC plus 
other statements that are particularly useful 
during integration. 

fi BASIC is a code-emitting, high-level language 
compiler designed specifically for the micropro- 
cessor application engineer or designer. M BASIC 
was designed for logic designers, engineers and 
programmers. It offers all of the advantages of a 
high-level language, including greater program- 
ming productivity, easier program maintenance, 
and application portability from one micropro- 
cessor to another. The compiler produces Assem- 
bly language statements that are subsequently 
processed through the assembler to produce 
object code for the microprocessor application. 
The advantages of /u. BASIC in a development 
effort are: 
Speeds programming time 

Coding is much easier and faster with /ii BASIC, 
/x BASIC programs require only a fraction of the 
number of statements that Assembly language 
programs require, /i. BASIC is also a simple 
language to learn. Most engineers can learn it 
themselves in a few days. Coding is not much 
more involved than writing down the series of steps 
needed to input, manipulate and output data. 
Permits code optimization 

When code must be reduced to fit memory, or 
when optimum execution speeds are needed, 
fj. BASIC statements can be intermixed with Assem- 
bly language statements in the same program. 
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Complete customer support 

Millennium provides the before and after sales 
support to assure you of a solution that will meet 
all your needs. 

Documentation — Millennium provides all soft- 
ware and hardware manuals in addition to 
complete service manuals. 
Warranty and service 

The Universal One and the Universal Emulator 
are fully warranted for 90 days. Return any de- 
fective unit to Millennium and it will be quickly 
repaired or replaced without charge. Millennium 
supports on-site, user maintenance with: 

□ Service Training 

□ A diagnostics and spare parts kit 

□ Fixed price board repairs 

Other arrangements are available based upon 

customer needs. 

For today's and tomorrow's development needs 

Universal One and Universal Emulator are the 
answers to today's and tomorrow's microproces- 
sor development needs. Both are specifically 
designed to operate with newer microprocessors 
as they become available. Neither instrument 
will become obsolete. 

The powerful universal disk operating system 
(UDOS) makes Universal One a useful tool in the 
hands of experienced and inexperienced pro- 
grammers alike, /u, BASIC is a valuable time and 
money saver because of the ease with which 
programs can be developjed and debugged. 

Universal One's and Universal Emulator's hard- 
ware emulation capabilities vastly ease the devel- 
opment effort from design to implementation. 

Join the productive generation with a Universal 
One or Universal Emulator Development Instru- 
ment. Both are available for delivery. 
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UNIVERSAL ONE COMMAND SET 

SYSTEM CONTROL COMMANDS 

ESC Returns control to operator 

SPACE BAR Stops and continues console output 

SUSPEND Suspends execution of active programs 

CONT Continues execution of a suspended program 

ABORT Aborts active UEXDS or User programs 

ASSIGN Connects Slave I/O Channel to system device 

CLOSE Disconnects and closes the channel 

SYSTEM OPTIONS 

SEARCH Controls the Automatic File search capability 

SYSTEM Designates the system Disk Drive 

DEVICE Informs UDOS of the peripheral device availability 

CLOCK Enables or disables Real Time Clock 

SYSTEM 

FORMAT 

VERIFY 

RENAME 

DUP 

LDIR 

DELETE 

COPY 

PRINT 



UTILITIES 

Formats the diskette for use by system 

Determines if bad blocks exist and catalogs them 

Changes the name of a Disk file or Disk identification 

Duplicates Diskettes 

Lists the directory of a specified Diskette 

Removes files from a Diskette 

Copies data from a file or device to another file 

or device 

Copies specified data from a file or device to another 

file or device with or without line numbers 



OBJECT PROGRAM UTILTTIES 

MODULE Wntes a Binary Load Module from Slave Memory to a 

file or device 
RHEX Reads a Hexadecimal object file into Slave Memory 

WHEX Writes a Hexadecimal object file from Slave Memory 

CSMS Tlranslales an SMS file and then compares the file 

with Slave Memory 
WSMS Writes a block of Slave Memory in SMS format 

SLAVE MEMORY AND CPU COMMANDS 

GO Starts user programs 

LOAD Reads Binary Load files into the Slave Memory 

XEO Combines LOAD and GO 

DUMP Displays the contents of Slave Memory on a specified 

device 
EXAM Allows you to examine or alter Slave Memory 

PATCH Allows you to alter Slave Memory with a string of Hexi- 

decimal characters 
STATUS Displays the status of the Slave CPU and the job being 

executed by it 
SLAVE Sets the Emulation mode of the Slave CPU 

SLAVE DEBUG COMMANDS 

BKPT Sets breakpoints 

CLBP Clears breakpoints 

RESET Generates a RESET pulse to the Slave CPU 

SET Allows you to set Slave CPU registers 

DSTAT Displays Debug Status 

TRACE Allows you to trace Slave CPU execution 

M BASIC COMMAND SET 

fi BASIC IS a simple, easily used, efficient compiler. The compiler 
produces an easy-to-read assembly listing after each statement which 
shows the machine instructions that are used to execute the logic of the 
statement. Data types and one dimensional arrays can be either one or 
two bytes. The DIM statement is used to specify the array size and 
optionally the origin of the array. Statement types include assignment, 
FOR, NEXT loop control, IF, GOTO, GOSUB, RETURN, INPUT, PRINT, 
and computed GOTO as well as computed GOSUB. 

The language does not support complex expressions. All expressions 
are in the form: 
A= B(opierationXI^ 

Any or all of the variables can be subscripted: 
Ad) = B(I) (operation) C (K) 

The simpler expression forms can also be used. For example: A= 5. 

Operations permitted are add (+ ). subtract (- ), multiply (x ), divide 
{/), AND, OR, XOR, NOT. shift right, shift left, shift right circular, shift 
left circular. The usual set of relational operations {<,>,=,< = . 
< = ,<>) are supported in the IF statement. 



TEXT EDITOR COMMAND SET 

INVOKING THE EDITOR 

EDIT INFILENAME 

OUTFILENAME 
EDIT FILENAME 



EDIT 



TEXT INSERTION 

INSERT STRING 

INPUT 

DELETION 

KILLN 

AUERATION 

SUBSTITUTE SSTRING 1 

SSTRING 2$ 
REPLACE STRING 

SEARCH 

FINDSSTRINGS 



INPUT/OUTPUT 
GET N (FILENAME) 



Designates the primary Input File and the 
primary Output File 

If Filename exists then Filename will be edit- 
ed to itself. If Filename is a new file it will be 
the primary Output file 
No primary Input on Output Files have been 
defined To Input or Output data, file name 
must be designated in the PUT & GET 
Commands 

Inserts the String before the current line in 

the Buffer 

Places the editor in the Input Mode 

Delete N Lines in the Buffer 

Substitutes Text String I with the Text in 

String 2 

Replaces the current line with the text String 

Searches the Buffer, starting at the current 
line, for the first line that contains the text 
String. 



Reads N Lines of data into the Buffer above 

the current line pointer 

Writes N Lines of data from the Buffer starting 

at the current line pointer 

Lists N Lines of data on the line printer 

Copies N Lines from Infile to Outfile 

* If the Filename is not specified, the primary 
Input or primary Output file is used as 
appropriate. 

LINE POINTER COMMANDS 



PUT N (FILENAME) 

USTN 

COPY N INFE£ 
(OUTFILE) • 



BEGIN 

END 

DOWNN 

UPN 

N 



Positions the line pointer to the first line of the 

Buffer 

Positions the line pointer to the last line plus 

one of the Buffer 

Moves the line pointer down N lines 

Moves the line pointer up N lines 

Displays the line number of the current 

line pointer 



UTIUTIES 

AGAIN 
FILE 



Performs the previous "repecrtable" command 
Transfers all the data and the remaining pri- 
mary Input file to the primary Output file. 
Terminates the edit session 

Displays N lines 

Terminates the edit session 

Defines the single CHAR as the tab character 

TABS CI C2 C3 Sets the tab position to the given columns CI, 

C2, C3 

Causes the command inside the angle 
bracket to be repeated "m" times 
Displays the Editor I/O Status 
Finds the error in MACRO String 
Inhibits or initiates typing after certain 
commands are executed by the editor 



TYPEN 
QUIT 
TAB CHAR 



m<COMMANDS> 
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BRIEF 



MACROS 

MACRO M = 

COMMANDLINE 
MACRO M 



MACRO definition command, M is an integer 
which identifies the MACRO number 
Command executes the MACRO M 
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Adaptability to various microprocessors 

comes from separating 

prototype- and system-related tasks; 

in-circuit emulation and 

new high-level language are bonuses 



'Universal' development system 
Is aim of master-slave processors 

by Robert D. CattertOn and Gerald S. Casilli, Millennium InlormaUon systems inc.. Sama Clara. Calil. 



n In the ever-changing world of the microprocessor, one 
clement is fixed: heavy investments in personnel training, 
software, and development aids can lock designers into a 
particular processor for their systems. Each recently 
introduced hardware and software development system, 
for example, is based on a particular family of devices 
and isn't easily adaptable to other families. What is 
needed to free the designer from design compromises 
that reduce performance or cost cfTcctiveness is a "uni- 
versal" development system that can accommodate 
many different microprocessors. 

A new system, called the Universal-One, achieves 
universality by a division into two functional areas. 
Tho.sc tasks that are related to the development system 
are assigned to a master central processing unit, and 
those that are prototype-related arc assigned to a second. 



or slave, c ph. As many as four different slaves may be 
installed simultaneously and individually used through 
operator commands. This multiple architecture enables 
the hardwiTc to support new microprocessors with the 
addition of a pc card containing the new slave ( in . 

Since the master processor need not be changed to 
accommodate new slave units, all of the operating 
system software remains the same. Presently, the system 
supports the 8080A and the 2650 central processors as 
slaves, with in-circuit emulation capability. It's easy to 
add other 8-bit processors to the system, and 16-bit 
devices may be added with only relatively little 
reconfiguration. 

Although universality is the basic objective, there are 
four other major requirements that today's development 
systems should satisfy. Use of a disk-based storage 
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system will achieve high throughput for maximum soft- 
ware-development productivity. A disk-based operating 
system should be specifically tailored for microprocessor 
development. The user's interface with the system should 
be simple and remain unchanged regardless of the 
processor under development. The test and debug capa- 
bilities should support development of hardware and 
software and their integration into an operating proto- 
type system. 

Functions 

The master c pu is responsible for all of those system 
services that are not prototype-dependent, such as: 

■ File management — the storage and retrieval of data 
and programs. 

■ Text editor — maintains text files contained on the 
disk. 

■ System input/output — the normal i/o activities 
between the standard system peripherals, such as flexible 
disk, printer, and terminal. 

■ System utilities, including programing of read-only 
memories for the final version of the prototype. 

■ Debug functions — the master executes the debug soft- 
ware and controls the slave through a separate debug- 
ging hardware module. 

The slave CPU's functions include: 

■ Program assembly each slave may be used as a 
resident assembler of prototype programs. 

■ Prototype-program execution- the prototype program 
is loaded into the slave memory and executed by the 
slave. 

■ Prototype i/o — any special input/output required in 
the prototype is performed by the slave. 



■ In-circuit emulation — a cable extends from the slave 
to the c PL; socket in the prototype. 

The system architecture (Fig. 1 ) includes a bus struc- 
ture to tic the components together and to permit the 
exchange of data and control signals. The basic bus 
design was governed primarily by the dual-memory and 
the multiplc-c PI architectures. Other design considera- 
tions for the bus were that the memory portion had to be 
able to handle 8- and 16-bit data words, and that the 
overall structure had to accommodate future higher- 
speed microprocessors. 

The system services the peripheral i/() devices and 
debug logic with interrupts rather than with polling. 
With an interrupt-driven system, the peripherals can get 
service when they need it, without waiting for their turn 
in the polling sequence. It also allows an eflicient 
software structure that is relieved of the overhead 
inherent to polling. In this way, maximum throughput is 
achieved. 

Memory structure 

The random-access memory of the system is organized 
as 65,536 bytes of common memory and a 16,384-byte 
master memory. The logic on the master cPU module 
allows appending any one of four 16-kilobyte segments 
of common memory (Fig. 2) to the master memory 
space. This allows master-slave communication for 
transfer of data during i/o service requests and gives the 
master access to program-trace information developed 
by the debug logic discussed later. 

Master-memory protection is accomplished by a 
special bus-control signal, which is sensed on the 
memory cards. Only the master c pi contains the 
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1. Two CPU*. The Universal-One system uses two central processing units— master and slave. In-circuit emulation is performed ttirough the 
slave CPU. which duplicates the type of microprocessor used In the prototype. The master CPU handles system-related functions. 



A new compiler 



To go along with the development system. Millennium has 
developed >jBasic, a high-level language compiler 
designed for microprocessor applications. Although it was 
tailored to meet the needs of engineers, it also provides a 
useful tool for the professional programer. 

The new compiler offers the advantages of a high-level 
language — greater programing productivity, easier pro- 
gram maintenance, and portability from one micropro- 
cessor to another. In the Millennium development system, 
it also provides a "universal" programing capability, since 
the same /iBasic statements can produce object 
programs for the different microprocessors. 

As shown in the figure. pBasic statements are first 
brought into the "statement-analyzer" software package, 
where they are converted for input to the code emitter. 
Then, depending on the microprocessor and resident 
assembler being used, the code emitter generates the 
assembly-language statements, which are subsequently 
passed through the assembler to produce object code for 
the selected microprocessor. This two-step compilation 
process gives the programer more flexibility when working 
out the program for the prototype. 

A major criticism of high-level languages in micropro- 
cessor applications is that more memory is used than with 
assembly languages, and execution is slower. However, 
^Basic allows the programer to intermix assembly 
language. In situations where a programer thinks it neces- 
sary, this intermixed assembly language may use the 
same labels and variables as does the ^Basic 
program. 

A debug-optimize report produced by the compiler 
helps avoid software error conditions that the two-step 
compilation process might cause. The report shows the 
MBasic statement followed by the assembly-language 
listing that was generated to perform the original state- 
ment. 

Typically, a programer would first code and debug the 
program without regard to memory or performance 
constraints. Then, when the program is functioning 
correctly, the debug-optimization report can be used to 
show those areas that may require assembly coding to 
optimize memory usage. Since memory comes in fixed 
increments, the most important optimization is usually 
done when the program size exceeds that specified incre- 
ment. If the program generated by ^(Basic does not 
exceed the memory increment available, then assembly- 
language optimization may not be needed. 

Performance optimization also can be in assembly 
language. Usually, some small portion of the code is used 
most of the time— for example, 10 to 15% of the code 
might be used 80 to 90% of the time. Consequently, a 
concentration on those heavily used portions will produce 
the greatest increase in performance. 

In its data and statement types, /iBasic is generally 
equivalent to PL/M. The length of the data element may 



be either 8 or 16 bits, and both 8 and 16-bit elements are 
supported at the same time. 
Examples of statement types are: 

■ LET — the assignment statement. 

■ FOR . . . NEXT — used for loop construction. 

■ IF— the test statement. 

■ GOTO, GOSUB. RETURN — control transfer statement. 

■ ON — for a computed GOTO or GOSUB. 

The ^Basic compiler features an ability to specify 
memory locations for arrays. This is quite important in 
connecting a peripheral device to the system. Many peri- 
pheral devices operate out of a dedicated-space memory. 
To conveniently interface a program written in a higher- 
level language to that device, the programer must be able 
to position the array in the same location in memory that 
the device is using. This is also very important in micropro- 
cessor systems where there is a ram/rom trade-off. The 
programer can control the origin of the portions of the 
program to be put in rom and ram. 

In comparing /iBasic with PL/M (the most widely used 
high-level language), it can be seen that the latter is a 
"richer" language. A professional programer is comforta- 
ble using PL/M and can take advantage of its greater 
complexity. However, the logic designer or other nonpro- 
fessional programer probably will have to expend some 
effort to learn enough about PL/M to be able to write 
programs using it. In contrast. j^Basic is easy to learn and 
use, while being quite effective. 
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circuitry to activate this control line. Thus, the slave 
processor cannot gain access to the master memory and 
destroy its contents or (through damage to the tile 
manager or part oF its data structure) the files them- 
selves, out on the disk. 

The slave can address the common memory as a 65- 
kilobyte or as a 32,768-word, 16-bit memory. This allows 



the 8-bit master to address a 16-bit slave memory as 
sequential bytes. 

There are also commands that permit the operator to 
display and alter common memory. He may inspect and 
change the contents of the mcinory, and he may display 
and alter the contents of the registers. He may interact 
with his program and change variables — change register 



i' 



Using the software 



The Millennium development system has many software 
features related to its use of a floppy disk for mass storage 
and the UDOS operating system for the disks. The system 
can have up to four floppy-disk drives all in use at the 
same time. A file name in use on one disk can be the same 
as one on another. The user can specify the file he wants 
by appending the floppy-disk drive number to the file 
name: i.e.. TESTPROG/1 or TESTPROG/2. 

Through use of the VERIFY command, a user can check 
the floppy disks to determine if any of the tracks are bad. 
The bad tracks are recorded in the disk's directory and 
thereafter are not allocated to a file. 

The user need not create a file or otherwise establish it 
before writing data on it. When he issues a UDOS 
command with a file name as an output device, the file will 
automatically be created, and the name will be placed in 
the directory for the floppy disk. 

The user need not allocate space for a file before using 
it, for disk space is dynamically allocated by UDOS as it is 
needed. When the file is closed, the space allocated is 
recorded in the directory. When the file is deleted, the 
space allocated Is treed up and made available for alloca- 
tion to other files. 

A file name may contain as many as eight alphanumeric 
characters and special characters. This allows the user to 
use names that are more indicative of the file content; i.e., 
PROGLIST rather than PRGLST. or, worse yet, PGLS. A 
disk file may contain anywhere from 1 to 311,296 data 
bytes. The user need not concern himself with extraneous 
data or otherwise keep track of the number of "real" data 
bytes in his file. 

The entire contents of a disk can be duplicated in 
another. This feature allows back-up of important disks 
and allows the user to recover if a file is inadvertently 
deleted, written over, or otherwise destroyed. 

Disks can be identified with a siring of up to 44 ASCII 
characters. Users can thus briefly describe the contents of 
the disk and the date it was created, and need not rely 
totally on the label, which could become marred or 
destroyed. 

The user can string together a group of files into one 
with a single UDOS command. This feature allows devel- 
opment of the source program in small, manageable 
pieces. Subsequently, all of the pieces can be combined 



and placed on a single file, which can be assembled. If an 
error shows up in the assembly, only that piece of the 
source program which contains the error need be edited. 
All of the pieces can then be combined again and the 
assembly repeated. 

All I/O operations can be assigned to channels by 
software. The user can assign any device attached to the 
system to any one of up to eight I/O channels and need 
not concern himself with the characteristics of the device. 
This feature allows the user to prepare programs whose 
input and output sources can be determined at run time. 
Channels can be assigned for a program externally 
through the console or internally by the program itself. 

A sequence of UDOS commands can be executed one 
at a time from a command file. The user can thus invoke 
any number of commands simply by issuing the name of 
the command file. The individual command can be filled 
with parameters that are given at the time the command 
file is invoked. Thus frequently used command sequences 
can be invoked simply. Command files can also be 
chained — the last UDOS command in a file can be the 
name of another file, allowing a series of jobs to be run in a 
batch mode, perhaps overnight, unattended. 

The text editor is line-oriented and has a command 
repertoire similar to those available on large time-sharing 
systems. The user can create a file of assembly-language 
statements or a data file by entering lines of text through 
the system console. Subsequently, he can insert lines 
anywhere in the file, delete lines, replace them, or modify 
part of the text on a line. 

During a text-editing session, the user can get lines of 
text from any file and merge them into the file being edited 
or put lines of text from the file being edited to any other 
file. This feature provides the capability of manipulating 
lines of text from several files and merging them into one 
file quickly and easily. With the text editor, the user can 
combine several text-editing commands into one complex 
command and then cause it to be executed several 
times. 

The user can set tabs dynamically and designate any 
console key as the tab character at any time during a text 
editing session. He can also issue UDOS commands and 
cause other system functions to be initiated during a text- 
editing session. 



contents or change the data elements being used in the 
debug process. 

The disk operating system 

A universal disk operating system called UDOS was 
developed for the multiple-tPU architecture. This soft- 
ware is executed by the master in its own totally 
protected master memory. The udos feature is floppy- 
disk-oriented, taking into account the characteristics and 
peculiarities of such disks. Many file-management func- 
tions usually performed by the user are performed 
automatically. The user need only direct that certain 
data be stored on a file or taken from a file. 

The operating system allows the user to develop 
microcomputer programs with a high-level language (see 
"A new compiler"), a symbolic assembler, or both. The 
user can prepare a program with a text editor, correct 



and modify it quickly and easily, assemble it, load the 
resulting object code into common memory (or into the 
prototype memory), and cause it to be executed under 
debug control. 

During execution, the program steps can be traced, 
breakpoints can be set, and memory can be inspected 
and altered as required. Subsequently, the program can 
be corrected or modified at the source level, using the 
text editor, then reassembled, loaded, and executed 
again for the next round of debugging, (see "Using the 
software"). 

In-circuit emulation 

Each slave contains circuitry to support in-circuit 
emulation. When the prototype becomes ready for test, 
all of the development-system resources become avail- 
able to it once the emulator cable is plugged into the 



microprocessor socket of the prototype. The operator can 
then use the system's debugging software to debug the 
prototype hardware and software and then to integrate 
them. 

The system supports two operating modes for emula- 
tion. In one, the user can substitute the memory of the 
development system for that of the prototype. In the 
other mode, when the prototype's memory becomes 
available and its i/o functions have been thoroughly 
tested, the operator can execute programs from the 
prototype memory while maintaining full control 
through the development system. 

When operating with the prototype memory, most of 
the system debugging features are still available. The 
user can use the address breakpoint and do a full trace. 
If this mode requires the programablc Rovi of the final 
prototype, the master can directly program the assem- 
bled instruction into the I'ROM chips. If the object resides 
on paper tape, it can be loaded into the system and 
transferred to the I'ROMs. 

The user can switch emulation modes at any time by a 
console command, with no hardware changes. The cable 
may be left attached to the slave even when the emula- 
tion feature is not in use. 

The development system's memory is comparable to 
the memory speed of most prototype systems, and thus it 
nearly simulates real-time operation when programs are 
executed from the system. When programs are executed 
from the prototype memory, the slave can operate at the 
the prototype's clock and memory speeds. Timing differ- 
ences resulting from the use of the umbilical cord are 
minimal. 

Master-slave Interaction 

When input/output from a master-controlled peri- 
pheral is required by a slave program, the slave CPU 
executes a service-request instruction, which causes the 
slave to pause temporarily while the master obtains the 
necessary data for the slave program. When the I/O 
requirements are completed, the master releases the 
slave so that it may continue the process of program 
execution. 

The debug logic is on a separate module and includes 
breakpoint registers, address-computation circuitry, two 
program-counter registers, and single-step and interrupt 
logic. The functions controlled by this logic are indepen- 
dent of the slave microprocessor and thus support the 
universal aspects of the system design for application to 
a variety of target processors. 

Part of the master-slave interaction includes control of 
breakpoint and trace operations. The master loads the 
breakpoint addresses under command from the user. 
When the memory address and operation from the slave 
match the breakpoint value, the program running under 
the slave pauses, and control is passed to the master. The 
debug module stores the slave's instruction-fetch address 
to enable the software to examine the prototype program 
and to interpret operating codes for the trace printout. 
Synchronization signals are provided to aid the user in 
triggering events necessary to debugging of prototype 
hardware. 

The two memory-address breakpoint registers may be 
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2. Memory addressing. The master CPU can address 32 kilobytes 
ol memory. Ol this total. 16 kilobytes are used by the disk-operating 
system, UDOS. while the other half can consist of any of four 16- 
kilobyle blocks in the common-memory addressing space. 

set to break on any of a variety of memory-access 
conditions. Another capability is a dynamic trace of the 
user program. On an instruction-by-instruction basis, the 
user can trace the activity of the program being 
executed, with a display of the location of the instruc- 
tion, its mnemonic, the register contents, and the state of 
the machine (such as the condition of the carry flip- 
flop). 

Dynamic trace may be performed on every instruc- 
tion, on instructions between two memory limits, or on 
only the jump instructions. The jump-instruction trace 
reduces print-out time and runs through the program 
faster. If the user isolates a problem area, he may go 
back to the full-trace mode and examine every one of the 
instructions. 

I/O and interrupts 

The functions associated with the master and slave 
CPUs dictate the need for separate master/slave 
input/output and interrupt structures. The master has a 
256-port I/O address space and a 32-level interrupt 
structure. Sixteen interrupts are devoted to debug func- 
tions and service requests. The other 16 are related to 
the system i/o 

The master card contains the i/o ports to support such 
standard peripheral devices as the dual-drive floppy disk, 
a line printer, and a cathode-ray tube or teletypewriter 
console. With the addition of a standard general-purpose 
I/O card, the system-related functions are easily 
expanded to support other peripherals, such as high- 



J. 































n 




CONSOLE 




ENDUSER 
SYSTEM 


1 






. 1 










1 OPTIONAL ; 

MOS 1 

1 PROM 1 

j PROGRAM ' 














FRONT PANEL 


1 












REMOTE 
INPUT 
DEVICE 












\ 




















MASTER 

CENTRAL 

PROCESSING 

UNIT 




DEBUG 
LOGIC 




SLAVE 

CENTRAL 

PROCESSING 

UNIT 




I GENERAL • 
1 PURPOSE 1 
I INPUT/ 1 
' OUTPUT 1 


































1 


>YSTE 


MBUS 






















1 OPTIONAL , 
1 BIPOLAR 1 
1 PROM 1 
I PROGRAM I 




MASTER MEMORY 




COMMON 
MEMORY 


























_J 



3. Smaller system. For applications in which users have already invested in software development aids, the Universal-One can be pared 
down to provide only emulation and PROM programing. Memory is much smaller, while the blocks shown in dashed lines are optional. 



speed paper-tape or card readers. 

The slave has a 256-port i <) address space and an 
eight-level priority-interrupt structure. It cannot directly 
address the system i/o. However, through the use of 
service requests to the master, it has full access to the 
system peripherals. 

The user also has the option of using a general- 
purpose I/O card as interface between the slave and its 
special devices, such as the prototype's keyboard or 
printer. In such a ca.se. the slave will perform its own to 
functions on those devices. The general-purpose card 
provides a full E!A-RS-232-compatible port and four 8- 
bit input/output ports. 

Expandable PROM programing 

Capability for programing erasable metal-oxide-semi- 
conductor and bipolar-fusible proms for the final version 
of the prototype is integral to the development system. 
Two card slots in the motherboard and three front-panel 
sockets arc provided with the standard system. Person- 
ality cards are available for programing the I702A MO.s 
PROM and the 82S1 15 4- and 8-bit bipolar family. New 
programing cards are easily substituted for other 
families of proms. 

As well as eliminating the need for a separate prom 
programer. this feature is more cost-effective, since dual 
I/O circuitry is unnecessary and operation is controlled 
by the ma.ster CPI rather than by a separate processor. 
The programing cards are interrupt-driven. freeing the 
master for other tasks during the programing of each 
byte. 

Even though a prom verifies correctly, it may lose 



charge or "grow back" a fusible link if not programed 
properly. Therefore, the cards have many protection and 
error-checking features such as over-voltage protection, 
current limiting to prevent overstrcssing. and power- 
failure protection against partial programing of the 
devices. 

The universal emulator 

Many companies already have some method of 
accomplishing the pure software-development function 
of assembling and editing programs, but they lack means 
of performing emulation or prom programing for use in 
the prototype system. Other companies have a complete 
microprocessor development system, but they arc 
involved in multi-project situations with one particular 
project fully occupying their development system. In 
either situation, companies may find a second version of 
the Millennium development .system useful. With an 
expanded front panel and a paring-down of the system 
memory to 12 kilobytes, it becomes a universal emulator 
and PROM programer (Fig. 3). 

All of the software debug functions for both emulation 
modes previously discussed will be retained. The basic 
functions, such as patch, dump, examine, breakpoint, 
and others will be resident in the prom. Only the trace 
program, which will change for each target slave, will be 
loaded into master memory from the console device. 
User programs may be entered into common memory 
either from the console device or remotely from a host 
computer via an EIA-RS-232 serial interface. Also, 
PROMS may be u.sed to hold user programs that will be 
executed in the prototype. D 
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